While client database platforms (i.e., home and business desktop computers) use hardware of a quality that is much lower than on server platforms, even server-class hardware (controllers, drivers, disks, and so forth) can cause data corruption such that a read operation does not return what the application wrote to the data store. Of course, this is clearly a more prolific problem with client database platforms (as opposed to server database platforms) for various reasons including without limitation to the increased probability of a client machine been arbitrary powered off in the midst of a write operation due to an unexpected power outage, which in turn leads to torn pages and potential database corruptions. (It is more common for server database systems to utilize uninterruptible power supplies to mitigate problems from power outages.) Media decay is another source of database corruptions, where the physical storage media quite literally wears out over time. And yet another source of concern regarding reliability is the detection and recovery from corruptions caused by the software errors both inadvertent (e.g., bugs) as well as pernicious (e.g., viruses).
Traditionally maintenance and repair of a databases has fallen to database managers and the like having a well-developed skill set and deep knowledge of database systems, or at least to individuals who are familiar with and regularly use database systems—by and large persons relatively skilled with regard to database technologies. On the other hand, typical consumer and business end-users of operating systems and application programs rarely work with databases and are largely ill-equipped to deal with database maintenance and repair issues.
While the disparate level of skill between these two groups has been largely irrelevant in the past, a database-implemented file system for an operating systems—such as the operating system disclosed in related the U.S. patent applications identified earlier herein in the section entitled “Cross-References”—creates a scenario where these lesser-skilled end-users will be faced with database maintenance and repair issues they will largely be unable to resolve. Thus a business/consumer database-implemented operating system file system, or “database file system” (DBFS) for short, must be able to detect corruptions and recover its databases to a transactionally consistent state and, in the cases of unrecoverable data loss, the DBFS must then guarantee data consistency at the level atomic change units to said data are maintained (i.e., at the “item” level for an item-based DBFS). Moreover, for DBFSs running by default in a lazy commit mode, the durability of transactions committed just before an abnormal shutdown is not guaranteed and must be accounted for and corrected.
Moreover, while business/consumer end-user will greatly benefit from automating DBFS maintenance and recovery, database managers and those of greater database skills will also benefit from a technical solution for general database maintenance and repair. It is commonplace in the art for database administrators to utilize database tools (for example, the database tuning advisor provided with SQL Server 2000), but these tools do not directly address reliability but instead provide a means by which backups of the database are administered and manage—and not in a mostly-automated fashion, but instead requiring substantial database administrator involvement, particularly when database backups are not available or other repair issues arise. Thus an automated solution to address database reliability would also be beneficial for database administrators and other skilled database users. The present invention provides just such a solution.